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1. Introduction 


The purpose of this document is to define the Community-based 
Administrative Framework for the SNMP version 2 framework (SNMPv2). 
The SNMPv2 framework is fully described in [1-6]. This framework is 
derived from the original Internet-standard Network Management 
Framework (SNMPv1l), which consists of these three documents: 


STD 16, RFC 1155 [7] which defines the Structure of Management 


Information (SMI), the mechanisms used for describing and naming 
objects for the purpose of management. 
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STD 16, RFC 1212 [8] which defines a more concise description 
mechanism, which is wholly consistent with the SMI. 


STD 15, RFC 1157 [9] which defines the Simple Network Management 
Protocol (SNMP), the protocol used for network access to managed 
objects. 


For information on coexistence between SNMPvl and SNMPv2, consult 
[10]. 


2. Components of the SNMPv2 Framework 


A management system contains: several (potentially many) nodes, each 
with a processing entity, termed an agent, which has access to 
management instrumentation; at least one management station; and, a 
management protocol, used to convey management information between 
the agents and management stations. Operations of the protocol are 
carried out under an administrative framework which defines 
authentication, authorization, access control, and privacy policies. 


Management stations execute management applications which monitor and 
control managed elements. Managed elements are devices such as 
hosts, routers, terminal servers, etc., which are monitored and 
controlled via access to their management information. 


2.1. Structure of Management Information 


Management information is viewed as a collection of managed objects, 
residing in a virtual information store, termed the Management 


Information Base (MIB). Collections of related objects are defined 
in MIB modules. These modules are written using a subset of OSI’s 
Abstract Syntax Notation One (ASN.1) [11]. It is the purpose of the 


Structure of Management Information for SNMPv2 document [1] to define 
that subset. 


The SMI is divided into three parts: module definitions, object 
definitions, and, trap definitions. 


(1) Module definitions are used when describing information modules. 
An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the 
semantics of an information module. 


(2) Object definitions are used when describing managed objects. An 
ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax 
and semantics of a managed object. 


(3) Notification definitions are used when describing unsolicited 
transmissions of management information. An ASN.1 macro, 
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NOTIFICATION-TYPE, is used to concisely convey the syntax and 
semantics of a notification. 

2.2. Textual Conventions 


When designing a MIB module, it is often useful to define new types 


similar to those defined in the SMI. In comparison to a type defined 
in the SMI, each of these new types has a different name, a similar 
syntax, but a more precise semantics. These newly defined types are 


termed textual conventions, and are used for the convenience of 
humans reading the MIB module. It is the purpose of the Textual 
Conventions for SNMPv2 document [2] to define the initial set of 
textual conventions available to all MIB modules. 


Objects defined using a textual convention are always encoded by 
means of the rules that define their primitive type. However, 
textual conventions often have special semantics associated with 
them. As such, an ASN.1 macro, TEXTUAL-CONVENTION, is used to 
concisely convey the syntax and semantics of a textual convention. 


2.3. Conformance Statements 


It may be useful to define the acceptable lower-bounds of 
implementation, along with the actual level of implementation 
achieved. It is the purpose of the Conformance Statements for SNMPv2 
document [3] to define the notation used for these purposes. There 
are two kinds of notations: 


(1) Compliance statements are used when describing requirements for 
agents with respect to object definitions. An ASN.1 macro, 
MODULE-COMPLIANCE, is used to concisely convey such requirements. 


(2) Capability statements are used when describing capabilities of 
agents with respect to object definitions. An ASN.1 macro, AGENT- 
CAPABILITIES, is used to concisely convey such capabilities. 


Finally, collections of related objects are grouped together to form 
a unit of conformance. An ASN.1 macro, OBJECT-GROUP, is used to 
concisely convey the syntax and semantics of a group. 


2.4. Protocol Operations 


The management protocol provides for the exchange of messages which 
convey management information between the agents and the management 
stations. The form of these messages is a message "wrapper" which 
encapsulates a Protocol Data Unit (PDU). 
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It is the purpose of the Protocol Operations for SNMPv2 document [4] 
to define the operations of the protocol with respect to the sending 
and receiving of the PDUs. 


2.5. Transport Mappings 


The management protocol, version 2 of the Simple Network Management 


Protocol, may be used over a variety of protocol suites. It is the 
purpose of the Transport Mappings for SNMPv2 document [5] to define 
how the SNMPv2 maps onto an initial set of transport domains. Other 


mappings may be defined in the future. 


Although several mappings are defined, the mapping onto UDP is the 
preferred mapping. As such, to provide for the greatest level of 
interoperability, systems which choose to deploy other mappings 
should also provide for proxy service to the UDP mapping. 


2.6. Protocol Instrumentation 


It is the purpose of the Management Information Base for SNMPv2 
document [6] to define managed objects which describe the behavior of 
a SNMPv2 entity. 


3. The Community-based Administrative Framework 


It is the purpose of an administrative framework to define an 
infrastructure through which effective management can be realized in 
a variety of configurations and environments. Specified as a part 
of, or as extensions of, an administrative framework are security 
mechanisms used to achieve an administratively-defined level of 
security for protocol interactions. 


The administrative framework for SNMPv2 identified in this document 
is the same framework as was defined for SNMPvl [9]. This 
administrative framework associates each message with a "community" 
as defined in [9]. Use of this administrative framework with SNMP 
Version 2 is commonly known as "Community-based SNMPv2 (SNMPv2C)." 


Specifically, Section 3.2.5 of [9] defines the concept of a 
community, and Section 4.1 of [9] defines the Elements of Procedure 
for generating and receiving messages. The following updates apply: 


(1) The types of access defined in Section 3.2.5 of [9] are updated 
by [1]. 


(2) The Elements of Procedure defined in Section 4.1 of [9] are 
updated with the additional requirement of incrementing the 
relevant statistics counter as defined in [6]. 
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(3) The requirement in the Elements of Procedure in Section 4.1 of 


[9] that the 


"the source transport address that a response 


message is sent from shall be identical to the destination 
transport address that the original request message was sent to" 


is deleted, i.e., 


the source transport address of a response 


message can be any transport address belonging to the agent. 


The form of a message is also taken from [9], 
a new version number is used in the message "wrapper". 
version number is necessary because of SNMPv2’s new PDU types 
With this one change, 


error codes [4], etc. 


COMMUNITY-BASED-SNMPv2 DEFINITIONS 
-- top-level message 


Message ::= 
SEQUENCE { 
version 
INTEGER { 
version(1) 


}, 


community 
OCTET STRING, 


data 
ANY 


END 


Note that with this administrative framework, 
value defined for the error-status component 
It may, 


‘authorizationError(16)’ 
of an SNMPv2 PDU [4] is unused. 
administrative frameworks. 


4. Security Considerations 


with the exception that 
Use of a new 
[4], 
the wrapper becomes: 


::= BEGIN 


-- modified from RFC 1157 


-—- community name 


-- PDUs as defined in [4] 


the 


however, be used with future 


Security issues are not discussed in this memo. 
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